(1) Field of the Disclosure
This disclosure relates generally to the field of analysis of computer program code and relates in particular to code profiling on stand-alone devices.
(2) Description of the Background
For optimizing software in Microcontrollers it is necessary to debug this software by using Profiling. Code profiling is measuring relatively the number each function is called and its duration. So, if a function A is e.g. 30% of the time active it would be useful for the software engineer to optimize the code in this function. If function B is e.g. 0.05% of the time active, it may be not be necessary to optimize it.
This Code profiling could be performed for several processors, e.g. ARM (a reduced instruction set computer (RISC) instruction set architecture (ISA) developed by ARM Holdings) processors, by a Trace Unit or another debug unit. Debugger software running on a PC use this embedded Trace Unit to do the code profiling and the results are shown on the PC in e.g. graphical way.
But for most of the ultra-low energy (ULE) devices (e.g. DECT and Bluetooth Low Energy devices or other devices having a low duty cycle) such a Trace unit is not available. Such a Trace unit on chip requires too much chip area and is hence too expensive. Therefore code profiling cannot be performed for these devices so far.
Also if this trace unit would be available it would be impossible to do this Code Profiling for an ULE device (or other devices having a low duty cycle), because this device is going to sleep mode for e.g. 20 seconds and wakeups for only e.g. 20 Milliseconds. This wake up time is too short for a debugger to set up its conversation with this ULE device and so the debugger can't use the trace functionality for doing his Code profiling.
Code profiling by setting port pins would also not be always possible because the ULE devices have only a limited amount of output pins. So there would be no pins available to set to ‘1’ and reset to ‘0’ for doing any kind of code profiling.
Therefore code profiling cannot be performed for devices having a short wakeup mode and therefore the code cannot be optimized these days. This could result in too long time spent in wakeup mode. Finally this relative long wake up time results in a shorter standby time of the ULE device.
Therefore there is a need for code profiling tools, which can be applied to devices having a relatively short wakeup time compared to the sleep time (low duty cycle).